Skip to content

Login and records implementation#122

Open
ukumar-ks wants to merge 2 commits intoreleasefrom
login-and-records-implementation
Open

Login and records implementation#122
ukumar-ks wants to merge 2 commits intoreleasefrom
login-and-records-implementation

Conversation

@ukumar-ks
Copy link
Copy Markdown

Login & Records Implementation

Summary

Adds KeeperSdk wrapper and interactive CLI examples for authentication and vault record operations.

Authentication

  • Password login — Master password authentication with retry logic and masked input.
  • Session token login — Login using an existing session token for pre-authenticated workflows.
  • Persistent login — Automatic session resumption via clone code from ~/.keeper/config.json.

Records

  • CRUD operations for vault records: list, get, add (v2/v3), update, delete, move, revision history, and password lookup with clipboard copy.

Sharing

  • Share and unshare records with other Keeper users via public key encryption.

@ukumar-ks ukumar-ks requested a review from tylerccarson April 13, 2026 12:27
@ukumar-ks ukumar-ks self-assigned this Apr 13, 2026
@socket-security
Copy link
Copy Markdown

socket-security bot commented Apr 13, 2026

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Added@​types/​node@​20.19.391001008195100
Addedts-node@​10.9.29610010082100
Addedtsconfig-paths@​4.2.09910010086100

View full report

@ukumar-ks ukumar-ks marked this pull request as ready for review April 13, 2026 12:29
@ukumar-ks ukumar-ks removed the request for review from THeflinKeeper April 13, 2026 12:30
@sali-ks sali-ks requested a review from craiglurey April 16, 2026 05:49
Copy link
Copy Markdown
Contributor

@tylerccarson tylerccarson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, adding a more user-friendly way to using the keeperapi package is a great idea. Going forward, we should treat everything in @keeper-security/keeperapi as the core library (which is primarily used and maintained by the browser extensions team), and add a new npm package (@keeper-security/keeper-sdk-javascript) intended for the public audience that's a convenient wrapper of the core library.

I've added some code-level feedback to the proposed additions here, please take a look at those.

Other than that:

  • we use main, not release (not sure who pushed release?). PR should be re-targeted
  • not sure if you want to do this yet, but ultimately we'll need to setup an npm workflow that publishes just @keeper-security/keeper-sdk-javascript. I can work on creating the package on the npm side when the time comes.
  • the additions are Node-centric, but I have a feeling there will be users who want to use this package in the browser as well. So 1) does this work in the browser and 2) if so, there should be examples that demonstrate a little bit

Comment thread KeeperSdk/package.json Outdated
@@ -0,0 +1,22 @@
{
"name": "keeper-sdk",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're going to publish as a separate package called @keeper-security/keeper-sdk-javascript-- name here should be updated accordingly

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ve updated the name field to @keeper-security/keeper-sdk-javascript as suggested.

Comment thread KeeperSdk/package.json
"types:ci": "tsc"
},
"dependencies": {
"@keeper-security/keeperapi": "17.1.0",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no change needed now-- but I will probably explore more formally re-organizing the project into npm workspaces after this. Then the packages will be implicitly linked, and share node_modules

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood, we’ll keep it as is for now and change later.

@@ -0,0 +1,36 @@
export const SdkDefaults = {
CLIENT_VERSION: 'c17.0.0',
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about whether we want to identify ourselves as Commander here with the c client version prefix

I've spoken with the backend team in the past already about adding a dedicated client version prefix for the js-sdk (i.e. js17.0.0), but not sure if any progress has been made.

@saldoukhov is that something you could help with? Or maybe @jgrein-keeper?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The backend does not seem to accept the client version yet. Testing with js17.0.0 was unsuccessful, and I am falling back to c17.0.0.

Comment thread KeeperSdk/src/utils/errors.ts Outdated
return err.message || err.result_code || err.error || 'Unknown Keeper error'
}
if (err instanceof Error) return err.message
if (typeof err === 'string') return err
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be a JSON string-- make want to attempt parsing as such first

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added parseJsonObjectIfPresent(s: string) helper to first check for JSON-like input and safely parse it using try/catch.

Comment thread KeeperSdk/src/utils/errors.ts Outdated
} catch {}
}
}
if (typeof err === 'string') return err
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see below

Comment thread KeeperSdk/src/auth/SessionManager.ts Outdated
}

private static base64urlDecode(str: string): Buffer {
return Buffer.from(str.replace(/-/g, '+').replace(/_/g, '/'), 'base64')
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use normal64Bytes from core lib


enum ResultCode {
Success = 'success',
OK = 'OK',
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the difference between Success and OK?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Success is used in legacy executeRestCommand flows (e.g. record_add) where success is indicated via result_code === 'success'. OK is used in the newer typed record/protobuf modify path as a fallback status when no per-record status is returned, but the overall call succeeds.

history: HistoryEntry[]
}

type RecordHistoryRequest = {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and associated types should be moved to the code lib (src/commands.ts).

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed—moved this to commands.ts as requested. The remaining types (HistoryEntry and RecordHistoryResult) are SDK-level, post-processed/decrypted result shapes rather than raw command transport types, so they are kept at the SDK layer.

return { recordUid, history }
}

function normalizeBase64(source: string): string {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use core lib function

Comment thread examples/sdk_example/README.md Outdated

## Prerequisites

- Node.js 16+
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Node 16 is pretty outdated, have you run these against it to be sure? We may want a specify a more recent minimum node version and not recommend something that probably has unpatched security vulnerabilties

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the recommended Node.js version from 16 to 22 LTS (or newer), as Node 20 is now in maintenance and any earlier versions are obsolete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants